1. Pourquoi une nouvelle notation

  • UML 1.x était complètement inadaptée :

    • Principalement pour les systèmes d’information

    • Peu de liens entre les diagrammes

    • Peu de liens entre les modèles et les exigences

  • UML 2.x n’est pas beaucoup mieux si ce n’est :

    • Implication des ingénieurs systèmes pour sa définition

    • Introduction du diagramme de structure composite

  • Standard De facto en génie logiciel

  • Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)

  • Stable et extensible (grâce notamment au mécanisme de profile)

  • Beaucoup d’outils disponibles

Mais…

  • Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de classe ou d'héritage par exemple)

  • Trop de diagrammes (13 sortes)

2. Introduction à SysML

2.1. Fiche d’identité

Note
Carte d’identité
  • Date de naissance : 2001!

  • Version actuelle : 1.3 (12/06/2012)

  • Auteurs principaux

    • Conrad Bock

    • Cris Kobryn

    • Sanford Friedenthal

2.2. Différence avec UML

images/diff.png
Figure 1. Liens entre UML et SysML

2.3. Qui est "derrière"?

Industrie

American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …

Vendeurs d’outils

Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …

Autres organisations

AP-233, INCOSE, Georgia Institute of Technology, AFIS, …

2.4. Organisation des différents diagrammes

images/Figure4.1.png
Figure 2. Les 9 diagrammes SysML et leur lien avec UML
images/Figure4.1-bis.png
Figure 3. Version abrégée des diagrammes

2.5. Différence entre modèle et dessin

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :

Table 1. Organisation

pkg

pkg, bdd

pkg

req

bdd, ibd, seq, par

uc, seq, st, act

par

3. Outils SysML

Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :

Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.

Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.

Important Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation.

4. Principes de base

  • L’entête du cadre, appelé cartouche, indique les informations sur le diagramme:

    • le type de diagramme (req, act, bdd, ibd, sd, etc.)

    • le type d'élément (package, block, activity, etc.)

    • le nom de l'élément

    • le nom du diagramme ou de la vue

Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un package, nommé "Context".

images/pacemaker-context.png
Figure 4. Exemple de diagramme SysML

5. Organisation

5.1. Fondements

On abordera :

  • Le Package Diagram

  • Les différent types de packages

  • Les organisations possibles

  • La notion de Namespaces

  • Les Dependencies

5.2. Le Package Diagram

  • Permet d’organiser les modèles en créant un espace de nommage (cf [namespace])

Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]). Le mécanisme qui permet de les organiser est le package (paquetage).

  • hiérarchie "système" (e.g., entreprise, système, composant)

  • types de diagrammes (e.g., besoins, structure, comportements)

  • par points de vue

  • etc.

5.3. Les différent types de packages

Il existe plusieurs types de package :

models

un package "top-level" dans une hiérarchie de package

packages

le type le plus classique : un ensemble d'éléments de modèles

model librairies

un package prévu pour être réutilisé (importé) par d’autres éléments

views

un package spécial pour représenter les points de vue

Note

Un point de vue (viewpoint) est utilisé pour matérialiser une perspective particulière de modélisation. Il possède des propriétés standardisés (concerns, language, purpose, etc.) et permettent d’indiquer qu’une vue (un packetage particulier, stéréotypé <<view>>) est conforme (dépendance <<conform>>) à un point de vue.

5.4. Les organisations possibles

Les modèles peuvent être organisés selon toutes sortes de considération :

  • par hiérarchie "système" (e.g., entreprise, système, composant, …)

  • par types de diagrammes (e.g., besoins, structure, comportements, …)

  • par cycle de vie (e.g., analyse, conception, …)

  • par équipes (e.g., architectes, [IPT], …)

  • par points de vue (e.g., sécurité, performance, …)

  • etc.

images/pkg-organisation2.png
Figure 5. Exemple d’organisation
images/pkg-organisation-modelview.png
Figure 6. Exemple d’organisation
images/pkg-organisation.png
Figure 7. Exemple d’organisation
images/pkg-topcased.png
Figure 8. Exemple d’organisation
Note
Organisation par défaut

"type" par défaut.

+ images/pkg-template.png images/pkg-topcased-default.png

+

5.5. La notion de Namespaces

Un package est un espace de nommage pour tous les éléments qu’il contient. Ainsi, dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.

Note
Namespace (OMG SysML v1.3, p. 23)
The package defines a namespace for the packageable elements.
Note

des éléments, c’est à dire le nom de l'élément prefixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).

5.6. Les dépendances

Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :

Dependency

une dépendance "générale", non précisée,
représentée par une simple flèche pointillée ----->

Use

l'élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype <<use>>

Refine

l'élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<refine>>

Realization

l'élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<realize>>

Allocation

l'élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype <<allocate>>

5.7.

de leur utilisation concrète dans la suite.

Table 2. Organisation

package

package

package

dependencies

5.8.

  1. Quels sont les 5 types de dépendances entre packageable elements ?

  2. À quoi cela peut-il servir de définir les dépendances (donnez des exemples concrets) ?

6. Les exigences

6.1. Fondements

On abordera :

  • L’organization des Requirements

  • Les Requirements properties

  • Les Requirements links

  • Les Requirements Diagrams

  • Les considérations sur la traçabilité

  • Annotations des Requirements

  • Les Use Case Diagrams (scénarios)

Note

L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation système. Voir le livre de référence pour

6.2. L’organisation des Requirements

6.2.1. Différents types d’organisation

Comme nous l’avons vu pour les packages, plusieurs types d’organisations sont possibles :

  • Par niveau d’abstraction

    • Besoins généraux (en lien avec les use cases par exemple)

    • Besoins techniques (en lien avec les éléments de conception)

  • Par point de vue

    • Besoins principaux (en lien avec les use cases)

    • Besoins spécifiques :

      • Fonctionnels

      • Marketing

      • Environnementaux

      • Business

  • etc.

6.2.2. Tableaux de Requirements

Les requirements sont généralement stockés dans des feuilles excel.

images/req-table.png
Figure 9. Exemples tableau d’exigences
images/req-modelio.png
Figure 10. Import Modelio de tableau d’exigences

6.3. Les Requirements properties

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

  • priority (high, low, …)

  • source (stakeolder, law, technical, …)

  • risk (high, low, …)

  • status (proposed, aproved, …)

  • verification method (analysis, tests, …)

Les principales relations entre requirement sont :

Containment

pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–)

Refinement

pour décrire un ajout de précision (<<refine>>)

Derivation

pour indiquer une différence de niveau d’abstraction (<<deriveReqt>>), par exemple entre un système et un de ses sous-systèmes

Note

Lorsqu’un cas d’utilisation possède plusieurs cas <<refine>> qui pointent vers lui, on considère que ces différents cas sont des options possibles de raffinement (cf. [conventions]).

images/req-exp1.png
Figure 11. Exemples de relations entre exigences

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons dans la partie transverse.

images/topcased-req-connections.png
Figure 12. Relations liées au requirements dans TOPCASED

6.5. Les Requirements Diagrams

Quelques exemples de req tirés de http://www.uml-sysml.org/sysml :

images/hsuv-reqs1.png
images/hsuv-reqs2.png

6.6. Les considérations sur la traçabilité

Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci sera abordé dans la partie transverse.

Note

En général chaque requirement devrait être relié à au moins un use case (et vice-versa!).

6.7. Annotations des Requirements

Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).

images/hsuv-reqs2.png
Figure 13. Exemples de rationale et problem

6.8. Les Use Case Diagrams (scénarios)

Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.

images/req-uc-relation.png
Figure 14. Exemple de lien entre use case et requirements

images/UCGestionNotes.png
Figure 15. Exemple de diagrammes des cas d’utilisation
images/uc.png
Figure 16. Autre exemple de diagrammes des cas d’utilisation
Tip

Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs.

6.9.

Les exigences sont très importantes en ingénierie système, plus en tout cas qu’en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme

Table 3. Déclinaison des Exigences

⊕–, <<deriveReqt>>

<<satisfy>>, <<refine>>

<<satisfy>> entre reqs et UC

<<refine>>

<<allocate>>

<<satisfy>>, <<verify>>

En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. [sysmod]).

Figure 17. Exemple de démarche (SYSMOD Zigzag pattern)

6.10.

  • Quelles sont les différences entre besoins et exigences ?

  • En quoi les cas d’utilisation sont-ils complémentaires des exigences?

    1. Quelle est la différence entre un package de type model et un package de type package?

7. L’architecture du système

7.1. Fondements

On abordera :

  • l’organisation du système et des modèles

  • les Block Definition Diagrams

  • les Internal Block Diagrams

  • les Parametric Diagrams (pour les contraintes physiques)

  • les Sequence Diagrams (diagramme de séquence système)

7.2. Organisation du système et des modèles

En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation ici.

Pour l’organisation du système, on trouve le plus souvent :

  • un diagramme décrivant le contexte (le système dans son environnement), décrit dans un block definition diagram (cf. [contextebdd])

  • un diagramme décrivant les éléments internes principaux du système, décrit dans un internal block diagram

7.3. Block Definition Diagrams

7.3.1. Principes de base

Un bdd peut représenter :

  • un package

  • un bloc

  • un bloc de contrainte (constraint block)

Un diagramme de bloc décrit les relations entre les blocs (composition, généralisations, …).

images/pacemaker-context.png
Figure 18. bdd du système dans son environnement

Un bloc est constitué d’un certain nombre de compartiments (Compartments) :

Properties

Operations

Les méthodes supportées par les instances du bloc.

Constraints

Les contraintes

Allocations

Les allocations

Requirements

Les exigences liées à ce bloc.

User defined

On peut définir ses propres compartiments

images/constraints.png
Figure 19. Exemple de définition de contraintes

7.3.2. Propriétés

On peut différencier 3 types de propriétés d’un bloc :

values

Des caractéristiques (quantifiables)

parts

Les éléments qui composent le bloc (cf. [ibd])

references

Les éléments auquel le bloc a accès (via des associations ou des agrégations)

Note

Les values sont ce qui se rapproche le plus des attributs de classes UML.

7.3.3. Value Types

images/valueType.png
Figure 20. Définition de Value Types.

7.3.4. Associations entre blocs

Il existe deux types de relations entre blocs :

  • l’association (y compris l’agrégation et la composition)

  • la généralisation/spécialisation

Association

Une association est un ensemble de liens permanents existant entre les instances de deux ou plusieurs blocs. On dira qu’une association lie plusieurs blocs ou que les blocs participent à l’association.

Une association possède plusieurs propriétés :

Dimension d’une association

Nombre de blocs mis en jeu par l’association
(binaire : 2, ternaire : 3, n-aire : n)

Note
Exemple d’association binaire

Soient les bloc Fournisseurs et Produits. On veut indiquer quels sont les produits susceptibles d’être fournis par chaque fournisseur et quels sont les fournisseurs susceptibles de fournir chaque produit.

Nom d’une association

Afin de clarifier les informations, il est important de nommer les associations.
Il existe trois façons de nommer une association :

  • un verbe à l’infinitif (e.g., Fournir)

  • un verbe conjugué avec un sens de lecture : Fournit > ou < Est fourni par

  • un rôle (placé à une extrémité de l’association)

Cardinalité

Indique à combien d’instances minimum et maximum du bloc d’en face est lié toute instance du bloc de départ. Elle est représentée par un couple (M..N).

Note

Attention, dans une cardinalité M..N, M doit toujours être inférieur ou égal à N. Exemple : 3..10.

Vers le code : que signifie vraiment une association?

En terme de logiciel, une association représente une contrainte sur la suite du développement : que ce soit un code (en langage orienté objet la plupart du temps) ou une base de donnée.

Pour reprendre l’exemple précédent, cela signifie concrètement au niveau d’un code par exemple que depuis une variable Produits on doit être capable d’accéder à une variable (correspondante) de type tableau (ou liste, ou …) de Fournisseurs.

Ce qui peut donner en java :

public class Produits
{
//Produits Attributes
private String idPro;
private String designation;
private float poids;

//Produits Associations
private List<Fournisseurs> fournisseurs;
...

En terme d’ingénierie système, on utilisera plutôt des associations spécifiques (l’agrégation et la composition).

Deux façon de représenter une propriété de type B

Note

Un moyen simple en terme logiciel de déterminer si une association A→B est une association dirigée (navigable dans un sens), une agrégation ou une composition est de raisonner en terme d’implémentation :

  • c’est une agrégation si b est initialisé dans le constructeur de A ;

  • c’est une composition si il est aussi détruit dans le destructeur de A ;

  • c’est une association dirigée simple si aucun des deux cas précédent ne s’applique.

Généralisation/spécilisation

Lorsque plusieurs blocs ont des caractéristiques en communs (propriétés, associations, comportement), il peut être utile de "factoriser" ces éléments en un bloc dont les autres vont "hériter". Quand on réalise ces liens hiérarchiques (on utilise souvent le terme "est un") en partant des blocs différents pour établir un nouveau bloc contenant les poins communs on parle de généralisation. À l’inverse, quand on constate qu’un bloc possède réellement plusieurs déclinaisons différentes on parle de spécialisation.

images/genspec.png
Figure 21. Exemple de lien de généralisation/spcécialisation

On retrouve cette association entre blocs, mais aussi entre acteurs, cas d’utilisation, etc.

7.4. Internal Block Diagrams

Un ibd décrit la structure interne d’un bloc sous forme de :

parts

Les parties qui constituent le système (ses sous-systèmes)

ports

Elément d’interaction avec un bloc

connecteurs

Liens entre ports

7.4.1. Parts

Les parties sont représentés par les éléments au bout d’une composition dans un bdd. Elles sont créés à la création du bloc qui les contient et sont détruites avec lui s’il est détruit (dépendance de vie).

Warning

Il ne s’agit pas de redessiner le BDD. Les parts sont des instances et non des classes (au sens objet).
Cela ne pose aucun problème à un ingénieur système, mais ça peut en poser à un ingénieur logiciel.

On représente les parts comme des bloc en traits pleins et les references comme des blocs en trait pointillés.

images/parts.png
Figure 22. Exemple de Parts
images/parts2.png
Figure 23. Autre exemple de Parts

7.4.2. Ports

Les ports :

  • préservent l’encapsulation du bloc

  • matérialise le fait que les interactions avec l’extérieur (via un port) sont transmise à une partie (via un connecteur)

  • les ports connectés doivent correspondre (kind, type, direction, etc.)

Note

Les ports définissent les points d’interaction offerts («provided») et requis («required») entre les blocs.
Les connecteurs peuvent traverser les "frontières" sans exiger de ports à chaque hiérarchie.

Exemples de flots

images/ports-flots.png

Exemples de flots multi-physique entre ports

images/flots.png

Ils peuvent aussi être de nature "flux physique".

Les Flux peuvent être :

  • atomiques (un seul flux),

  • composites (agrégation de flux de natures différentes).

Note

Un flow port atomique ne spécifie qu’un seul type de flux en entrée ou en sortie (ou les deux), la direction étant simplement indiquée par une flèche à l’intérieur du carré représentant le port. Il peut être typé par un bloc ou un Value Type représentant le type d’élément pouvant circuler en entrée ou en sortie du port.

7.5. Parametric Diagrams

Ce diagramme utilise 3 concepts clefs :

  • Constraints (un type de bloc)

  • Parametric diagram (un type d'ibd)

  • Value binding

7.5.1. Contraintes

C’est un bloc particulier :

  • avec un stéréotype ≪constraint≫ (au lieu de bloc)

  • des paramètres en guise d’attributs

  • des relations liant (contraignant) ces paramètres

images/constraints.png

7.5.2. Diagramme paramétrique

C’est une forme particulière de Internal Block Definition

images/param.png

7.5.3. Value Binding

Une fois les contraintes exprimées, il faut lier les paramètres (formels) à des valeurs (paramètre réel). C’est l’objet des Value Binding.

Pour assigner des valeurs spécifiques, on utilise des Block Configurations;

7.6. Diagrammes de séquence système

Il permet de décrire les scénarios des cas d’utilisation sans entrer dans les détails. Il convient donc mieux à l’ingénierie système qu’un diagramme de séquence classique (cf. section sur les seq).

Exemples de dss

images/dss.png

7.7.

En résumé, il existe plusieurs diagrammes permettant d’exprimer la structure du système à concevoir. En fonction du niveau de détail nécessaire on peut voir les sous-systèmes comme des boîtes noires (des blocs) ou comme des boîtes blanches (grâce à l'ibd correspondant).

Table 4. Place des aspects structurels

package

bdd par

bdd par ibd dss

bdd par ibd dss

7.8.

  1. Quelles sont les différences entre une association dirigée (), une composition (losange noir) et l’agrégation (losange blanc) ?

  2. Puisqu’un bdd me donne souvent la liste des sous-systèmes (liens de composition), pourquoi ai-je besoin d’un ibd ?

8. Le comportement du système

8.1. Fondements

On abordera :

  • les Use Case Diagrams (scénarios)

  • les Sequence Diagrams

  • les State Machines

  • les Activity Diagrams

8.2. Use Case Diagrams

Les éléments de base :

Acteurs

les principaux acteurs (leur rôle) qui participent (on parle parfois d’acteurs principaux) ou qui bénéficient (on parle alors d’acteurs secondaires) du système.

Cas d’utilisation

représente un ensemble d’actions réalisées par le système intéressant pour au moins un acteur

Association

participation d’un acteur à un cas d’utilisation.

Sujet

le domaine étudié (qui peut être une partie seulement de tout le système, pas forcément modélisé dans son ensemble)

Tip

Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs.

8.3. Le Diagramme des Cas d’Utilisation

  • les UC (Use Case ou Cas d’Utilisation)

  • les acteurs (principaux et secondaires)

  • les relations

    • entre acteurs et Use Case

    • entre Use Cases

Note

On notera simplement uc pour signifier "diagramme des UC"

8.3.1. Cas d’Utilisation (Use Case)

Exemple de cas d’utilisation (UML)

Retrait par carte bancaire

Scénario principal

L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.

Scénario alternatif n°1

Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.

Exemple de codification de l’UC

UC01 ou RetraitCB (pour Retrait par carte bleue)

Précisions

Un cas d’utilisation peut être précisé par :

  • une description textuelle

Note

Dans les outils, cette "précision" se manifeste par le fait que l’on "attache" généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un Use Case → nouveau seq).

8.3.2. Acteur

On peut trouver plusieurs types d’acteurs :

  • extérieurs au système (cf. actor Diagramme d’UC ci-après)

    • les acteurs principaux

    • les acteurs secondaires

  • exemples de types d’acteurs prédéfinis dans UML :

    • <<utility>>

    • <<process>>

    • <<thread>>

Note

On peut utiliser des liens de généralisation/spécialisation entre acteurs pour représenter les possibilités pour le spécialisé d’avoir les mêmes prérogatives (notamment en terme d’utilisation du système) que le généralisé.

8.3.3. Relations entre acteurs et Use Case

En général, une simple association relie acteurs et Use Case. On peut également orienter ces associations en plaçant une direction (flèche vide) au bout de l’association.

8.3.4. Relations entre Use Case

Après avoir lister les cas d’utilisation, il est utile de les organiser et de montrer les relations entre eux. Plusieurs relations sont possibles :

Extension (<<extend>>)

Indique que le Use Case source est éventuellement exécutée en complément du Use Case destination (cas particulier, erreur…). Le point précis où l’extension peut se produire est appelé extension point (surtout utile quand il existe plusieurs extensions pour un même cas)

Inclusion (<<include>>)

Indique que le Use Case est inclus obligatoirement dans un autre Use Case (notion de sous-fonction par exemple)

Généralisation

Relation entre un Use Case général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute (différents modes d’utilisation d’un système par exemple, ou encore différents acteurs impliqués)

Tip
Notation dans le diagramme d’UC

On n’utilise généralement <<include>> que dans le cas où le sous-cas d’utilisation est inclut dans plusieurs UC. Si ce n’est pas le cas, il est généralement englobé dans l’UC.

8.3.5. Pour construire un UC (de manière générale)

  1. identifier les acteurs

  2. identifier les cas d’utilisation

  3. structurer en packages

  4. finaliser les diagrammes de cas d’utilisation (ajouter les relations)

Note

Certains méthodologistes (comme T. Wielkins) préconisent de ne pas utiliser les acteurs et les cas d’utilisation (cf. son blog)

8.3.6. Exemples complets (UML)

Service comptable
Gestion des notes

8.4. Sequence Diagrams

8.4.1. Généralités

Autre exemple de diagramme d’UC

Il permet de :

  • modéliser les interactions entre blocs

  • séquencer ces interactions dans le temps

  • représenter les échanges de messages

  • spécifier les scénarios des cas d'études

Les éléments qui composent ce diagramme sont :

Participants

les éléments en interaction (des blocs généralement)

Lignes de vie

des lignes verticales qui permettent d’indiquer un départ ou une arrivée d’interaction

Barres d’activation

pour matérialiser quand l'élément est actif

Messages

ce qui "circule" d’un élément à l’autre (signal, appel de méthode, …)

Diagramme de séquence

Warning

Les participants (et leur ligne de vie) représentent des instances de blocs (souvent "anonymes").

8.4.2. Exemple

8.4.3. Notions avancées

Exemple de diagramme de séquence

On peut également représenter des instructions itératives et conditionnelles au travers de cadres d’interaction :

  • loop (boucle)

  • alt (alternative)

  • opt (optionel)

  • par (parallèle)

  • region (région critique - un seul thread à la fois)

Exemple algorithme / diagramme

8.4.4. Exemple de conceptions

Note
Conception "objet"

On utilise le diagramme de séquence pour représenter des algorithmes et des séquencements temporels. Lorsque le comportement se rapproche plus d’un flot, on utilise le diagramme d’activité (cf. section sur le act).

8.4.5. Lien entre UC, DSS et DS

La décomposition hiérarchique permet une description "TOP-DOWN" du système à réaliser.

On fait un Diagramme de Séquence Système pour chaque cas d’utilisation (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.

Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les blocs composant le système (issus du bdd) collaborent pour réaliser le traitement demandé.

8.5. Diagramme d'états

Le DS correspondant

Ce diagramme représente les différents états possibles d’un bloc particulier, et comment ce bloc réagit à des événements en fonction de son état courant (en passant éventuellement dans un nouvel état). Cette réaction (nommée transition) possède un événement déclencheur, une condition (garde), un effet et un état cible.

Le diagramme d’états comprend également deux pseudo-états :

  • l’état initial du diagramme d’états correspond à la création d’une instance ;

  • l’état final du diagramme d’états correspond à la destruction de l’instance.

Un exemple de diagramme d'état (R,UK)

Lorsqu’un état nécessite lui-même plus de détails, on créé un état composite (aussi appelé super-état) qui est lui-même une machine à état. On peut ainsi factoriser des transitions déclenchées par le même événement (et amenant vers le même état cible), tout en spécifiant des transitions particulières entre les sous-états. Il est également possible d’attacher un diagramme d'état (composite) à un état pour garder une représentation hiérarchique.

Un diagramme d'état peut représenter des régions concurrentes (dont les activités peuvent évoluer en parallèle), graphiquement représentées par des zones séparées par des traits pointillés. Chaque région contient ses propres états et transitions.

Il existe encore d’autres concepts avancés que nous ne présenterons pas dans cette introduction car ils sont beaucoup moins utilisés (entry, exit, transition interne, etc.).

8.6. Diagrammes d’activité

Les diagrammes d’activité (Activity Diagrams) est utilisé pour représenter les flots de données et de contrôle entre les actions. Il est utilisé pour raffiner en général un cas d’utilisation. Il est utilisé pour l’expression de la logique de contrôle et d’entrées/sorties. Le diagramme d’activité sert non seulement à préciser la séquence d’actions à réaliser, mais aussi ce qui est produit, consommé ou transformé au cours de l’exécution de cette activité.

images/act-pcmk1.png
Figure 24. Exemple de diagramme d’activité (tiré de [SeeBook2012])

Les éléments de base du diagramme d’activité sont :

  • les actions,

  • les flots de contrôle entre actions,

  • les décisions (branchements conditionnels),

  • un début et une ou plusieurs fins possibles.

8.7. Actions

Une action représente un traitement ou une transformation. Les actions sont contenues dans les activités, qui leur servent alors de contexte.

8.8. Flots

Un flot de contrôle permet le contrôle de l’exécution des noeuds d’activités. Les flots de contrôle sont des flèches reliant deux noeuds (actions, décisions, etc.).

Le diagramme d’activité permet également d’utiliser des flots d’objets (reliant une action et un objet consommé ou produit). Les object flow, associés aux broches d’entrée/sortie (input/output pin) permettent alors de décrire les transformations sur les objets manipulés.

Un flot continu
Figure 25. Un exemple de flot continu (UK)

On utilise pour cela des stéréotypes : <<continuous>> et <<discrete>>.

Note

Par défaut, un flot est supposé discret.

8.9. Décision

Une décision est un noeud de contrôle représentant un choix dynamique entre plusieurs conditions (mutuellement exclusives). Elle est représentée par un losange qui possède un arc entrant et plusieurs arcs sortants. Il existe plusieurs noeuds de contrôle (cf. Fig. [Control]) :

fork

Un fork est un noeud de contrôle représentant un débranchement parallèle. Il est représenté par une barre (horizontale ou verticale) qui possède un arc entrant et plusieurs arcs sortants. Le fork duplique le "jeton" entrant sur chaque flot sortant. Les jetons sur les arcs sortants sont indépendants et concurrents.

join

Un join est un noeud de contrôle structuré représentant une synchronisation entre actions (rendez-vous). Il est représenté par une barre (horizontale ou verticale) qui possède un arc sortant et plusieurs arcs entrants. Le join ne produit son jeton de sortie que lorsqu’un jeton est disponible sur chaque flot entrant (d’où la synchronisation).

flow final

Contrairement à la fin d’activité qui est globale à l’activité, la fin de flot est locale au flot concerné et n’a pas d’effet sur l’activité englobante.

merge

La fusion est l’inverse de la décision : le même symbole du losange, mais cette fois-ci avec plusieurs flots entrants et un seul sortant.

images/flow-ctrl.png
Figure 26. Les différents contrôles de flow SysML

8.10. Réutilisation

Les activités peuvent être réutilisées à travers des actions d’appel (callBehaviorAction).

images/act-call.png
Figure 27. Exemple de callBehaviorAction (UK)

8.11.

Il existe de nombreux diagrammes pour exprimer les comportements. Ces modèles sont importants dans la mesure où ils peuvent servir à valider le futur système vis-à-vis de ces comportements exprimés. Ils ne sont donc véritablement utiles que lorsqu’ils sont couplés à des outils de simulation ou d’analyse (cf. [Analyse]).

Table 5. Place du Comportement

package

uc ds

dss ds act

sm

8.12.

  1. Comment, pour exprimer un comportement, savoir si j’ai besoin d’un diagramme de séquence plutôt qu’un diagramme d’activité ou encore d’une machine à état ?

8.13. Exercices

8.13.1. Diagramme des cas d’utilisation

Placez dans un diagrammes des cas d’utilisation les différents acteurs et cas correspondant à l'étude de cas suivante (en indiquant les relations) :

Pour faciliter sa gestion, un entrepôt de stockage envisage de concevoir un système permettant d’allouer automatiquement un emplacement de stockage pour chaque produit du chargement des camions qui convoient le stock à entreposer. Lors de l’arrivée d’un camion, un employé doit saisir dans le système les caractéristiques de chaque article ; le système produit alors une liste où figure un emplacement pour chaque article. Lors du chargement d’un camion les caractéristiques des articles à charger dans un camion sont saisies par un employé afin d’indiquer au système de libérer les emplacements correspondant.

9. Les aspects transversaux

Table 6. Aspects transversaux

9.1. Fondements

On abordera ici les aspects transversaux comme :

  • la traçabilité des exigences

  • les mécanismes d’allocation

  • le diagramme paramétrique

9.2. Traçabilité des exigences

Nous les regroupons ici dans une matrice spécifique (qui se lit dans le sens des relations, par exemple un élément de structure comme un bloc <<satisfy>> une exigence).

Table 7. Traçabilité

<<deriveRqt>>, <<refine>>, <<copy>>

<<allocate>>, <<satisfy>>

<<allocate>>

<<refine>>

Comme indiqué dans le tableau ci-dessus, en général, le lien de raffinement est utilisé entre une exigence et un élément comportemental (état, activité, uc, etc.) tandis que l’allocation concerne principalement les éléments de structures.

XXX Mettre un exemple avec tous ces liens.

9.3. Mécanismes d’allocation

préciser quel élément conceptuel (comme un comportement ou une activité) est alloué sur quel élément physique.

Il est possible d’exprimer cette allocation de plusieurs manières.

Parler du <<AllocatedTo>>, compartiments des blocs et autres annotations. Parler des zones d’allocation dans les machines à états où les diagrammes d’activités par exemple. Parler des <<allocate>>.

9.4. Diagramme paramétrique

C’est une forme particulière de Internal Block Definition. Nous avons abordé cela dans la section [param].

images/param.png

Note

Certaines approchent (cf. [MéDISIS]) utilisent des feuilles excel pour traduire les diagrammes paramétriques et contrôler l’impact des changements de valeurs de tel ou tel paramètre.

9.5.

9.6.

  1. Quelles sont les différences entre <<satisfy>> et <<allocate>> ?

  2. Pourquoi est-il important de relier un use case à au moins un requirement ?

  3. L’inverse est-il aussi important ?